home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / sys / amiga / programmer / 1910 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  4.1 KB
  1. Path: comma.rhein.de!serpens!not-for-mail
  2. From: mlelstv@serpens.rhein.de (Michael van Elst)
  3. Newsgroups: comp.sys.amiga.programmer
  4. Subject: Re: Demo/game to OS friendly part II
  5. Date: 24 Jan 1996 21:31:03 +0100
  6. Organization: dis-
  7. Message-ID: <4e64u7$a2u@serpens.rhein.de>
  8. References: <4e0jhq$f0q@sunsystem5.informatik.tu-muenchen.de> <4e114i$4o8@serpens.rhein.de> <4e371l$92b@sunsystem5.informatik.tu-muenchen.de> <4e3jld$la@serpens.rhein.de> <4e5k20$rva@sunsystem5.informatik.tu-muenchen.de>
  9. NNTP-Posting-Host: serpens.rhein.de
  10.  
  11. fischerj@informatik.tu-muenchen.de (Juergen "Rally" Fischer) writes:
  12.  
  13. >|> If you want hacks then shut down the system and reboot afterwards.
  14. >naah, shut down, zzzt zzzt, how should I perform parallel reload from
  15. >hd then ? :)
  16.  
  17. Simple and easy: you shouldn't, you mustn't, you can't.
  18.  
  19. >|> And stand for it.
  20. >Or embed it into OS as much as possible, tell the user, and stand for it.
  21.  
  22. You just create lots of garbage with this. You know that, I am telling
  23. you for years and you "stand for it". That's the basic problem here.
  24.  
  25. >But writepixelarray8 is known to be slower on current chipset Amigas...
  26.  
  27. Doesn't mean that you have to use hacks.
  28.  
  29. >Well, the medium version, checking for native bitmaps (can I assume
  30. >blitter present then ?)
  31.  
  32. No. Why ?
  33.  
  34. >and using less optimal 4 pass blitter should
  35. >also still be a la RKM,
  36.  
  37. Sure. I don't call this is a hack.
  38.  
  39. >but will loose on 2x2 quite much speed
  40. >vs the hack.
  41. >realtimish demos on 1x1 will also loose quite some fps.
  42.  
  43. That's your opinion.
  44.  
  45. >So if user got AGA and PAL he will be happy chosing the hack.
  46.  
  47. Ah sure. He probably also feels happy that you didn't write
  48. software that works on his next Amiga model because there
  49. is no such model.
  50.  
  51. >|> >yes, in can optimize that way, but this could still be less ideal
  52. >|> >than direct render to vram.
  53. >|> 
  54. >|> Sure. In the same way that WaitTOF() could suddenly busy-wait, no ?
  55.  
  56. >Do I read this right as "I don't believe direct render can be faster" ?
  57. >not in demos with realtime-fx, especially 50Hz ones ?
  58.  
  59. No, you don't read this right. You simply _assume_ that the driver is
  60. less than ideal than direct render to vram. This assumption is as
  61. valid is your other assumption about WaitTOF() to use busy-waiting.
  62.  
  63. >struct display *getdisplay(320,256,8,MODE_DIRECT_RENDER|MODE_LORES);
  64.  
  65. Sorry, fails.
  66.  
  67. >Well, heehee, there have been cases where even a A1200 rendering to
  68. >_CHIPMEM_ was faster than using fastmem+copy.
  69.  
  70. Sure ? And there have been cases where it was slower.
  71.  
  72. >This proves my point 
  73.  
  74. No.
  75.  
  76. >(which is "rendering to vram could be faster on a certain machine
  77. >running a certain gfx-engine").
  78.  
  79. You said that you need direct rendering to vram _because_ that is
  80. faster. And that's wrong.
  81.  
  82. >mhm, how does your idea handle the case "direct render" ?
  83.  
  84. I don't care. I might even support this as an unportable exception.
  85. But more likely I would make the driver API include those higher
  86. level functions that would benefit from direct rendering. The user
  87. code can then ignore this topic algotether.
  88.  
  89. >ugh. look at all those "cool workastions", SGI, wow how cool it is,
  90. >we love it, but no fullscreen animation, or jerk jerk. just because
  91. >they got no lores.
  92.  
  93. No. Because the system software does not support fullscreen animation.
  94.  
  95. >The philosophy of Amiga has always been beeing efficient.
  96.  
  97. Poking hardware isn't efficient from a broader view.
  98.  
  99. >At least the AMIGA hardware can do it, but some people tell 
  100. >not to use it ;)
  101.  
  102. If that produces junk, sure.
  103.  
  104. >that's ok, if it can be done far beyond a frame (it's DMA should not
  105. >slow down direct render) then it's ok.
  106.  
  107. Why ? It could still be faster than anything you are using now.
  108.  
  109. >But wouldn't it be more annoying if you got a quick cpu but run also 
  110. >quarterscreen due to not having lores ? would be really lame.
  111.  
  112. I know what is lame.
  113.  
  114. >no. If I had designed the interface, setdisplay(struct display *) would
  115. >handle the outzoom without application noticing it.
  116.  
  117. Your interface would just work on one hardware. Same as your c00l c0d3.
  118.  
  119.  
  120. -- 
  121.                                 Michael van Elst
  122.  
  123. Internet: mlelstv@serpens.rhein.de
  124.                                 "A potential Snark may lurk in every tree."
  125.